[AWS] 複数の Transit Gateway をまたぐ通信を試してみた

こんにちは、菊池です。

先週行われたDevelopers.IO 2019 Tokyoにて、Transit Gatewayを使ったルーティング制御について登壇させて頂きました。

Developers.IO 2019 Tokyo 登壇資料「ハイブリッド/マルチVPC環境を構成するためのAWSネットワーク完全理解」 #cmdevio

この登壇にあたっての検証・資料作成の中で、さらに応用させることでいろいろな構成が可能ではないかと思い検証しています。その中から、複数のTransit Gatewayをホップさせる構成を試したので紹介します。

複数Transit Gatewayをまたがる構成

試してみたのは以下のようなイメージです。3つのVPC、

• VPC1：10.0.0.0/16
• VPC2：172.16.0.0/16
• VPC3：192.168.0.0/16

を直列に、2つのTransit Gatewayを用いて接続し、その両端で通信が可能かを試します。

冒頭の登壇資料でも触れましたが、これは従来のVPC Peeringでは仕様上の制約によって単純には（具体的には、中間のVPCで双方向NATをしない限り）疎通不可能な構成です。これが、Transit Gatewayでは可能かどうかを検証しました。

検証結果

結論から言うと、疎通できました。

それぞれのVPC、Transit Gatewayで以下のようなルートテーブルを設定することで、複数のTransit Gateway、中間VPCをまたがる通信が可能です。（細かいので、拡大してみてください）

サブネットに割り当てるVPCルートテーブルおよびTransit Gatewayのルートテーブルで、疎通先のCIDRをちゃんとStatic Routeで追加することで、お互いに通信が可能になります。

Peeringと違い、Transit Gatewayでは

• アタッチ先のVPCにENIをもつ
• ルートテーブルが編集可能

という性質により実現ができているようです。

まとめ

複数のTransit Gatewayをまたぐ構成で通信可能であることを検証しました。

使いどころとしては、複数のアカウントにまたがってTransit Gatewayを共有するような構成で、自組織用と共有用で明確に分ける場合などが考えられます。自組織内のTransit Gatewayでは、ルートテーブルのアソシエーションとプロパゲーションを有効化しておき自由に疎通可能とし、共有Transit Gatewayではきめ細かくルート制御をしたいといったケースです。

一方で、アタッチメント数、通信量が増加しますので、当然利用料金も増えることに注意が必要です。